Web services are typically stateless. So if a web service request is delivered to a target that is capable of processing the request, then the request is deemed to have been delivered correctly. If the target is not found or is incapable of processing the request then an error will occur and be sent back to the requester. In these cases, validation that a request has been correctly routed is trivial since any target that exists and is capable of processing the request is considered valid.
However, not all web services are stateless. Making requests to a stateful web service requires an addressing mechanism. Web service requests addressed to stateful web services must not merely be delivered to a web service instance capable of processing the request, but also to the specific web service instance to which the request was addressed. The simplest way to address a stateful web service is a direct addressing system that contains the unique address of the stateful web service itself. Such direct addressing is generally reliable, however it is limited in certain capabilities such as high-availability.
Indirect addressing is commonly required whenever an intermediate node (or nodes) take part in the routing of a request. An intermediate node for the purposes of this discussion is an entity which retargets or reroutes the request. For example, a node could be a separate process, such as a Web server, or indeed a component, for example routing logic running in the requester. Routing code is commonly used for workload management and highly available functionality. Web servers and proxy servers are commonly used to support real-world system topologies, including the use of firewalls to provide security, whereby the address of the target web service is not addressable directly by the client.
Whenever indirect addressing is used, there is an increased possibility that a web service request addressed to a stateful web service will be incorrectly routed to the wrong server. This could be for any number of reasons including but not limited to failover or workload managed relocation of stateful web service instances, incorrect administration and data propagation delays in routing data. In such cases, it is a non-trivial task for user code to distinguish between the cases where, on the one hand, a received request has been wrongly routed to a server that does not host the stateful web service instance and, on the other hand, a received request has been correctly routed to an appropriate server but the stateful web service instance no longer exists.